home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000518_timbl@www3.cern.ch _Fri Jan 8 11:54:45 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB

  1. Return-Path: <timbl@www3.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA28289; Fri, 8 Jan 93 11:54:45 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA06000; Fri, 8 Jan 1993 12:09:44 +0100
  6. Received: by www3.cern.ch (NX5.67c/NX3.0S)
  7.     id AA02814; Fri, 8 Jan 93 12:09:41 +0100
  8. Date: Fri, 8 Jan 93 12:09:41 +0100
  9. From: Tim Berners-Lee <timbl@www3.cern.ch>
  10. Message-Id: <9301081109.AA02814@www3.cern.ch>
  11. Received: by NeXT.Mailer (1.87.1)
  12. Received: by NeXT Mailer (1.87.1)
  13. To: Dan Connolly <connolly@pixel.convex.com>
  14. Subject: Re: dealing with new-lines 
  15. Cc: "Thomas A. Fine" <fine@cis.ohio-state.edu>, www-talk@nxoc01.cern.ch
  16. Reply-To: timbl@nxoc01.cern.ch
  17.  
  18.  
  19.  
  20. For what it is worth, the way the CERN implementations are supposed to work is:
  21.  
  22.     MIXED elements
  23.     
  24. Within a MIXED element,  newlines are treated as word breaks.  The effect of  
  25. this is that if the imaginary output cursor has a non-white character to the  
  26. left of it, then a space is introduced.  This means that any number of newlines  
  27. will only produce one white space character.  [It involves a horrid "are we in  
  28. the middle of a word?" flag.]
  29.  
  30. Spaces, however, always produce spaces, so multiple spaces will come out as  
  31. multiple spaces.
  32.  
  33.     XMP
  34.     
  35. Within <XMP> I went all the way and said that from the trailing > of <XMP>
  36. to the beginning <of </XMP> all data was litteral, including newlines.  
  37. Therefore example sections typically are marked up as
  38.  
  39. <XMP>This is an example line
  40.  
  41. </XMP>
  42. That was an example.  There are no new lines between the <XMP> and the example  
  43. line because the XMP section causes a paragraph break, and the style for the  
  44. normal paragraph specifies a minimum white space after each paragraph. Beacuse  
  45. each XMP section is like a black box, any white spce inside it would not be  
  46. seen by the white space management logic which overlaps the white spaces  
  47. required around successive paragraphs, and extra white spce would result.
  48.  
  49.     PRE
  50.  
  51. By the way, I think we agreed (I gave in) that the <PRE> sections would have
  52. siugnificant newlines.  Your manuals, Tom, have <p> as well as newlines, which  
  53. gives double spacing on my browsers.  So I tread newlines as newlines in all
  54. the <PRE> element just as XMP.
  55.  
  56.     SGML generation
  57.     
  58. Off the top of my head I think what happened was in Mixed elements, I generate  
  59. the newlines instead of spaces in PCDATA when the line gets a bit long, and  
  60. also insert them before open tags like <H3> which cause paragraph breaks  
  61. anyway.  As an anchor tag need not cause a word break even, I do NOT insert  
  62. them before an <A>, but rather always output "<A\nNAME=%s" so that the
  63. HREF attribute (generally the line length buster) starts atthe beginning of  a  
  64. line. 
  65.  
  66.  
  67.     Tim
  68.  
  69.